公众号注册
2018 年深冬的下午，在需求评审会后，产品向在场的前端开发和客户端开发提出了一个问题：为什么你们评估工期需要等到最终设计稿交付？产品说他之前和设计师、技术同学合作时，技术同学是可以不用等到交付才动工的。听到这个问题的刹那间，作为和前端开发打了5年交道的我，沉默了大概10s。最终还是简单的发表了一下观点：研发同学根据设计稿评估的研发周期是最精准的。
事后就想围绕着这个问题写点文字，思来想去没有动笔，而是去买了几本书：《学习敏捷:构建高效团队》、《敏捷革命》、《人月神话》。希望自己读过书后，对这个问题能有新的认知。
今晚准备从公司回家时，收到了一条这样的消息，突然就想趁着书没读完先写写自己目前的想法。
为什么评估工期需要等到设计稿交付？
回答这个问题，需要先明确题干中评估工期指的是大致的工期还是准确的工期。在文章开头提到的语境中，是指开发的功能达到可提测状态的准确时间。
其实这个问题可以从软件研发之外的行业找到答案。比如：负责房屋精装修的工人是否需要完整的效果图才可以给出装修耗时？汽车生产线是否需要设计稿确定后才可以准确评估生产一台汽车的时间？以目前我的理解，两个问题的答案都是肯定的。
从工程的角度，精准的时间评估是依赖精准的前置条件的。
产品是否需要交付视觉稿后，前端才可以开工？
那么有没有一些灰度空间呢？比如：我和负责房屋装修的人是好朋友，在房屋装修的各种问题上我们已经交流了很久，此时在效果图没有最终确定前，他告诉我房屋装修所需要的时间，此时我会相信吗？要生产的新车型的很多零件，都是在其他汽车上广泛应用的配件；汽车的组装方案是基于另外一辆汽车做的修改；组装汽车的工人有着丰富的同类型汽车组装经验，此时是否能给出生产一台汽车所耗费的时间？以目前我的理解，两个问题的答案可能也都是肯定的。
这种灰度空间是哪些因素在起作用呢？大致列举众多因素中的几个：更多的交流、彼此的信任、业界通用的解决方案、丰富的实战经验。
这种灰度空间有什么问题吗？目前我认为其中最大的问题在于风险变得更大。朋友被其他事情占用了大量时间导致没有足够精力负责装修怎么办？原以为可以直接使用的汽车配件等到最终组装时发现尺码差了0.3cm，导致没办法顺利组装怎么办？
所以说，从实践的角度，工程化的事情中是存在一定的灰度空间的。如果这种灰度空间掌控不好，会给工程带来更大的风险。
